Query Execution and Optimization with Autonomic Error Recovery from Network Failures in a Parallel Computer System with Multiple Networks

ABSTRACT

An apparatus and method for a database query execution monitor determines if an network error or low performance condition exists and then where possible modifies the query. The query execution monitor then determines an alternate query execution plan to continue execution of the query. The query optimizer can re-optimize the query to use a different network or node. Thus, the query execution monitor allows autonomic error recovery for network failures using an alternate query execution. The alternate query execution could also be determined at the initial optimization time and then this alternate plan used to execute a query in the case of a particular network failure.

RELATED APPLICATIONS

This application is related to a co-filed application to Barsness, et.al., Query Execution And Optimization Utilizing A Combining Network In AParallel Computer System, Ser. No. ______ filed on ______, which isincorporated herein by reference.

This application is related to a co-filed application to Barsness, et.al., Query Optimization In A Parallel Computer System To Reduce NetworkTraffic, Ser. No. ______ filed on ______, which is incorporated hereinby reference.

This application is related to a co-filed application to Barsness, et.al., Query Optimization In A Parallel Computer System With MultipleNetworks, Ser. No. ______ filed on ______, which is incorporated hereinby reference.

BACKGROUND

1. Technical Field

This disclosure generally relates to database query execution andoptimization, and more specifically relates to query execution andoptimization with autonomic error recovery from network failures in aparallel computer system of multiple nodes and multiple networks.

2. Background Art

Databases are computerized information storage and retrieval systems. Adatabase system is structured to accept commands to store, retrieve anddelete data using, for example, high-level query languages such as theStructured Query Language (SQL). The term “query” denominates a set ofcommands for retrieving data from a stored database. The query languagerequires the return of a particular data set in response to a particularquery.

Many large institutional computer users are experiencing tremendousgrowth of their databases. One of the primary means of dealing withlarge databases is that of distributing the data across multiplepartitions in a parallel computer system. The partitions can be logicalor physical over which the data is distributed.

Massively parallel computer systems are one type of parallel computersystem that have a large number of interconnected compute nodes. Afamily of such massively parallel computers is being developed byInternational Business Machines Corporation (IBM) under the name BlueGene. The Blue Gene/L system is a scalable system in which the currentmaximum number of compute nodes is 65,536. The Blue Gene/L node consistsof a single ASIC (application specific integrated circuit) with 2 CPUsand memory. The full computer is housed in 64 racks or cabinets with 32node boards in each rack. The Blue Gene/L supercomputer communicatesover several communication networks. The compute nodes are arranged intoboth a logical tree network and a 3-dimensional torus network. Thelogical tree network connects the computational nodes so that each nodecommunicates with a parent and one or two children. The torus networklogically connects the compute nodes in a three-dimensional lattice likestructure that allows each compute node to communicate with its closest6 neighbors in a section of the computer.

In massively parallel computer systems such as the Blue Gene parallelcomputer system, recovering from hardware failures is important to moreefficiently utilize the computer system. Recovering from a failure mayallow a sophisticated application to continue to operate on differentportions of the system or at a reduced speed to prevent the total lossof accumulated data prior to the failure that would result fromrestarting the system.

Database query optimizers have been developed that evaluate queries anddetermine how to best execute the queries based on a number of differentfactors that affect query performance. In the related applications, aquery optimizer rewrites a query or optimizes query execution forqueries on multiple networks. On parallel computer systems in the priorart, the database and query optimizer are not able to effectivelyovercome a failure of a network while executing a query. Without a wayto more effectively execute and optimize queries, multiple networkcomputer systems will continue to suffer from inefficient utilization ofsystem resources to overcome network failures and process databasequeries.

SUMMARY

In a networked computer system that includes multiple nodes and multiplenetworks interconnecting the nodes, a database query execution monitordetermines if a network error or low performance condition exists andthen where possible modifies the query. The query optimizer thendetermines an alternate query execution plan to continue execution ofthe query. The query optimizer can re-optimize the query to use adifferent network or node. When a query encounters problems on a givennetwork, the query can be restarted using a different network in thetopology without user intervention for a seamless execution of thequery. Thus, the query execution monitor allows autonomic error recoveryfor network failures where the query optimizer determines an alternatequery execution plan. The alternate query execution could also bedetermined at the initial optimization time and then the alternate planused to execute a query in the case of a particular network failure.

The disclosed examples herein are directed to a massively parallelcomputer system with multiple networks but the claims herein apply toany computer system with one or more networks and a number of parallelnodes.

The foregoing and other features and advantages will be apparent fromthe following more particular description, as illustrated in theaccompanying drawings.

BRIEF DESCRIPTION OF DRAWINGS

The disclosure will be described in conjunction with the appendeddrawings, where like designations denote like elements, and:

FIG. 1 is a block diagram of a computer with a query optimizer thatrewrites a query to take advantage of multiple nodes and multiplenetwork paths of a parallel computer system;

FIG. 2 is a block diagram of a compute node to illustrate the networkconnections to the compute node;

FIG. 3 is a block diagram representing a query optimizer system;

FIG. 4 is a block diagram of a network file record that containsinformation about network utilization;

FIG. 5 is a block diagram of a database table for an example modifying aquery that is partially completed at the time of a network failure;

FIG. 6 is a block diagram of a database table with information that isextracted from the table by partial execution of the query shown in FIG.7 executed against the database table shown in FIG. 5;

FIG. 7 is a query that executes on the database tables shown in FIGS. 5and 6 to illustrate an example of modifying a query after partialexecution before a network failure;

FIG. 8 is a modified version of the query shown in FIG. 7;

FIG. 9 is a method flow diagram for monitoring query execution andre-optimizing the query after detection of a network failure in aparallel database system; and

FIG. 10 is a method flow diagram to create and update network filerecords that are used by the query execution monitor and the queryoptimizer.

DETAILED DESCRIPTION 1.0 Overview

The disclosure and claims herein are related to query optimizers thatdevelop and optimize how a query accesses a database. For those notfamiliar with databases, queries, and optimizers, this Overview sectionwill provide additional background information.

Known Databases and Database Queries

There are many different types of databases known in the art. The mostcommon is known as a relational database (RDB), which organizes data intables that have rows that represent individual entries or records inthe database, and columns that define what is stored in each entry orrecord.

To be useful, the data stored in databases must be able to beefficiently retrieved. The most common way to retrieve data from adatabase is to generate a database query. A database query is anexpression that is evaluated by a database manager. The expression maycontain one or more predicate expressions that are used to retrieve datafrom a database. For example, let's assume there is a database for acompany that includes a table of employees, with columns in the tablethat represent the employee's name, address, phone number, gender, andsalary. With data stored in this format, a query could be formulatedthat would retrieve the records for all female employees that have asalary greater than $40,000. Similarly, a query could be formulated thatwould retrieve the records for all employees that have a particular areacode or telephone prefix. One popular way to define a query usesStructured Query Language (SQL). SQL defines a syntax for generating andprocessing queries that is independent of the actual structure andformat of the database. When the database receives a query request, itproduces an access plan to execute the query in the database. The accessplan may be stored in a plan cache for use with subsequent queries thatuse the same access plan. In the prior art, a tool known as a queryoptimizer evaluates expressions in a query and optimizes the query andgenerates the access plan to access the database.

Query optimizers can also be utilized in a parallel computer system.This application and claims are directed to a database query optimizerthat is invoked by a query execution monitor. The query optimizerre-optimizes a query to overcome a network failure as describe furtherbelow.

2.0 Detailed Description

In a networked computer system that includes multiple nodes and multiplenetworks interconnecting the nodes, a database query execution monitordetermines if an network error or low performance condition exists.Where possible, the query is modified and then the query optimizerdetermines an alternate query execution plan to continue execution ofthe query. The query execution monitor allows autonomic error recoveryfor network failures where the query optimizer determines an alternatequery execution. The examples herein are directed to a query optimizerthat executes on a massively parallel computer system such as a BlueGenesupercomputer.

The BlueGene supercomputer family developed by IBM includes thousands ofcompute nodes coupled together via multiple different networks. In theBlueGene architecture, the torus and logical tree networks areindependent networks, which means they do not share network resourcessuch as links or packet injection FIFOs. When nodes are interconnectedwith different independent networks, as in the case of the BlueGenearchitecture, the use of one or more networks can affect the performanceof database queries that include resources on one or more nodes andnetworks. A query optimizer can now take advantage of multiple networkswhen executing a database query. Known query optimizers take many thingsinto consideration when optimizing a database query, but no known queryoptimizer has optimized queries by rewriting or optimizing the query toexecute on multiple networks to optimize performance of a network andthe query.

The detailed description is given with respect to the Blue Gene/Lmassively parallel computer being developed by International BusinessMachines Corporation (IBM). However, those skilled in the art willappreciate that the mechanisms and apparatus of the disclosure andclaims apply equally to any parallel computer system with multiple nodesand networks.

FIG. 1 shows a block diagram that represents a massively parallelcomputer system 100 that incorporates many of the features in the BlueGene/L computer system. The Blue Gene/L system is a scalable system inwhich the maximum number of compute nodes is 65,536. Each node 110 hasan application specific integrated circuit (ASIC) 112, also called aBlue Gene/L compute chip 112. The compute chip incorporates twoprocessors or central processor units (CPUs) and is mounted on a nodedaughter card 114. The node also typically has 512 megabytes of localmemory (not shown). A node board 120 accommodates 32 node daughter cards114 each having a node 110. Thus, each node board has 32 nodes, with 2processors for each node, and the associated memory for each processor.A rack 130 is a housing that contains 32 node boards 120. Each of thenode boards 120 connect into a midplane printed circuit board 132 with amidplane connector 134. The midplane 132 is inside the rack and notshown in FIG. 1. The full Blue Gene/L computer system would be housed in64 racks 130 or cabinets with 32 node boards 120 in each. The fullsystem would then have 65,536 nodes and 131,072 CPUs (64 racks×32 nodeboards×32 nodes×2 CPUs).

The Blue Gene/L computer system structure can be described as a computenode core with an I/O node surface, where communication to 1024 computenodes 110 is handled by each I/O node that has an I/O processor 170connected to the service node 140. The I/O nodes have no local storage.The I/O nodes are connected to the compute nodes through the logicaltree network and also have functional wide area network capabilitiesthrough a gigabit ethernet network (not shown). The gigabit Ethernetnetwork is connected to an I/O processor (or Blue Gene/L link chip) 170located on a node board 120 that handles communication from the servicenode 140 to a number of nodes. The Blue Gene/L system has one or moreI/O processors 170 on an I/O board (not shown) connected to the nodeboard 120. The I/O processors can be configured to communicate with 8,32 or 64 nodes. The service node uses the gigabit network to controlconnectivity by communicating to link cards on the compute nodes. Theconnections to the I/O nodes are similar to the connections to thecompute node except the I/O nodes are not connected to the torusnetwork.

Again referring to FIG. 1, the computer system 100 includes a servicenode 140 that handles the loading of the nodes with software andcontrols the operation of the whole system. The service node 140 istypically a mini computer system such as an IBM pSeries server runningLinux with a control console (not shown). The service node 140 isconnected to the racks 130 of compute nodes 110 with a control systemnetwork 150. The control system network provides control, test, andbring-up infrastructure for the Blue Gene/L system. The control systemnetwork 150 includes various network interfaces that provide thenecessary communication for the massively parallel computer system. Thenetwork interfaces are described further below.

The service node 140 manages the control system network 150 dedicated tosystem management. The control system network 150 includes a private100-Mb/s Ethernet connected to an Ido chip 180 located on a node board120 that handles communication from the service node 140 to a number ofnodes. This network is sometime referred to as the JTAG network since itcommunicates using the JTAG protocol. All control, test, and bring-up ofthe compute nodes 110 on the node board 120 is governed through the JTAGport communicating with the service node.

The service node 140 includes a network monitor 142. The network monitor142 comprises software in the service node and may include software inthe nodes. The service node 140 further includes a query optimizer 144.The query optimizer 144 may execute on the service node and/or be loadedinto the nodes. The service node 140 also includes a query executionmonitor 146 that monitors execution of a query and consults the networkmonitor to determine if a query is executing or if there is a networkerror. The network monitor 142, the query optimizer 144, and the queryexecution monitor are described more fully below.

The Blue Gene/L supercomputer communicates over several communicationnetworks. FIG. 2 shows a block diagram that shows the I/O connections ofa compute node on the Blue Gene/L computer system. The 65,536computational nodes and 1024 I/O processors 170 are arranged into both alogical tree network and a logical 3-dimensional torus network. Thetorus network logically connects the compute nodes in a lattice likestructure that allows each compute node 110 to communicate with itsclosest 6 neighbors. In FIG. 2, the torus network is illustrated by theX+, X−, Y+, Y−, Z+ and Z− network connections that connect the node tosix respective adjacent nodes. The tree network is represented in FIG. 2by the tree0, tree1 and tree2 connections. Other communication networksconnected to the node include a JTAG network and a the global interruptnetwork. The JTAG network provides communication for testing and controlfrom the service node 140 over the control system network 150 shown inFIG. 1. The global interrupt network is used to implement softwarebarriers for synchronization of similar processes on the compute nodesto move to a different phase of processing upon completion of some task.Further, there are clock and power signals to each compute node 110.

Referring to FIG. 3, a system 300 is shown to include multiple nodes 305coupled together via multiple networks 310A, 310B, 310C, . . . , 310N.The system 300 represents a portion of the computer system 100 shown inFIG. 1. The multiple networks are also coupled to a network monitor 142that monitors the networks and logs the network characteristics in anetwork file 322. The network monitor 142 provides input data to thequery optimizer (or optimizer) 144. In the preferred implementation, themultiple networks are independent networks so a problem with one networkdoes not affect the function of a different network. However, networksthat are dependent may also be used. The query execution monitor 146 isconnected to the query optimizer and monitors execution of a query anddetermines if a query is executing properly or if there is a networkerror. The query execution monitor is described more fully below

The query execution monitor 146 monitors execution of a query. Theexecution monitor 146 may be incorporated as part of a database engineor a stand-alone software operating on the service node 140 and/or thecompute node 110 (FIG. 1). The query execution monitor 146 monitorsexecution of a query and consults the network monitor to determine if aquery is executing properly or if there is a network failure of somekind preventing completion of the query. A network failure can be acomplete hardware failure of a single network or where a network can beconsidered failed due to significantly reduced performance. A networkmay be considered failed if the response time to complete a request istoo large, or if a network parameter such as re-transmits, latency,connection resets and other like parameters are outside a given range orbeyond a given threshold. The network monitor may store performanceinformation for network resources as described below with reference toFIG. 4.

When the query execution monitor detects a failure as described above,the query execution monitor may then check if data from a partiallycompleted query can be reused and the query re-written to use the datafrom the partially completed query. This process is described furtherbelow. The query execution monitor then invokes the query optimizer 144to re-optimize the query to use a different network resource other thanthe network resource that failed. The query optimizer will thendetermine whether there are other networks available to execute thequery and then will develop an execution plan to optimize the query touse the alternate network resources. The related applications listedabove provide additional methods and details for the query optimizer toselect the alternate network resources to re-optimize the query.Alternatively, the query optimizer may develop alternate access plansfor one or more potential failures at the time of initial optimization.The query optimizer then stores the alternate access plans until thequery execution monitor detects the occurrence of a failure associatedwith one of the alternate access plans.

FIG. 4 illustrates an information structure for storing performanceinformation that can be used by the query optimizer to determine how tooptimize queries over multiple nodes and networks in a parallel computerdatabase system. FIG. 4 illustrates a network file 322 that is used bythe query optimizer. The network file 322 is maintained by the networkmonitor 142 (FIGS. 1, 3). Network file 322 preferably includes multiplerecords as needed to record status information about the networks in thecomputer system. The illustrated network file 322 has records 410A,410B, and 410C. The network file records 410A through 410C containinformation such as the network identifier (ID), a time stamp, currentutilization, future utilization, network availability, latency and thepercentage of retransmits. The current utilization represents how busythe network is in terms of bandwidth utilization at the time of thetimestamp. Where possible, the future utilization of the network ispredicted and stored. Similar to the node availability described above,the availability of the network indicates whether the network isavailable or not. Data stored in the network file 322 includeshistorical and real time information about the network status andloading.

FIGS. 5, 6 and 7 illustrate an example of autonomic error recovery froma network failure with query re-optimization. FIG. 5 represents adatabase table 500 named “Employees”. The database table 500 has rows ofdata 510A-510N where each row holds data for an individual employee. Thelast row 510N is blank but represents that there may in fact be moresrows in the database but it is abbreviated for clarity. Each row of data510A-510N includes an employee identification number (E_ID), name,salary and start data of the employee represented in that row.Similarly, FIG. 6 shows a database table named Managers 600. TheManagers table 600 includes a list of employee IDs and departmentsmanaged for employees that are also managers. The Managers table 600 hasa record 610A for an accounting department manager with an employee IDof “89”, and a record 610B for a production department manager with anemployee ID of “90”.

FIG. 7 shows a query 700 for illustrating an example of a queryexecuting to partial completion before a network failure is detected bythe query execution monitor. The query 700 operates on the Employee 500and Manager 600 tables described above with reference to FIGS. 5 and 6.The query 700 selects all records from the Employees database 500 thatare not managers. To accomplish this, the query selects 710 employeesfrom the Employees database 500 where the employee ID 720 is not foundin the second select statement 730. The second select statement 730returns all the Managers IDs from the Managers database 600. Thus, thesecond select statement 730 operating on the Managers database 600returns 612 the data “89” and “90” 614 as shown in FIG. 6.

When part of a query has completed execution before a network failureoccurs, the query execution monitor will determine whether the query canbe rewritten to conserve the completed portion of the query. In theillustrated example above, if the second select statement of the queryis complete, then the data 614 for this completed portion of the querycan be conserved by rewriting the query. FIG. 8 shows the rewrittenquery 800, where the data 614 from the select statement is included asliteral values 810 from the query run previously. In the alternative,the rewritten query 800 may include a pointer to a temporary datastructure that contains the data 614 from the second select statement.

FIG. 9 shows a method 900 for a query execution monitor to performautonomic error recovery from a network failure with queryre-optimization on a computer system with multiple nodes and multiplenetworks. The method 900 first receives a query (step 910). Next,optimize the query in the manner known or as described in the relatedapplications (step 920), alternatively, optimize the query withalternative access plans that can be used when network failures areencountered as described above. Further, on subsequent loops to step920, re-optimize the query for the detected network failure to use analternate network resource. If the required networks are not available(step 930=no) then return an error (step 940) and the method is done. Ifthe networks are available (step 930=yes) then initiate the query (step950). The query execution monitor then monitors the query execution(step 960). The query execution monitor monitors the query to detect thethree conditions listed in the next three question blocks (step 970,980, 985). If a network failure is detected (step 970=yes) then go tostep 990. If poor performance of the query execution is detected (step980=yes) then go to step 990. If the query is not complete (step 985=no)then continue monitoring the query execution (step 960). If the query iscomplete (step 985=yes) then the method is done. Continuing with step990, check if the query is partially complete (step 990=yes) then modifythe query if possible to save the completed portion of the query (step995) and return to re-optimize the query (step 920). If part of thequery is not complete (step 990=no) then return to re-optimize the query(step 920). After re-optimizing the query (step 920) then continue withthe method flow as described above until the method is done.

FIG. 10 shows a method 1000 for the network monitor 142 in FIGS. 1 and 3to determine network traffic and network characteristics. The method maybe executed on the compute nodes or on the service node 140 shown inFIG. 1. This method is executed for each network to govern databasequery activity in the database. For each network (step 1010), determinethe current network utilization (step 1020). If possible, future networkutilization is predicted (step 1030). Future network utilization couldbe predicted based on previous statistics stored in the network file.Predicted future network utilization could also be based on history ifthe application has been run before or has an identifiable pattern, andcould be based on information provided about the application. Forexample, certain types of applications traditionally execute specifictypes of queries. Thus, financial applications might execute queries tospecific nodes while scientific applications execute queries to all ofthe nodes. The network latency for each node is determined (step 1040).The average latency is computed and logged (step 1050). The performanceof the network may then be determined based on the computed averagelatency (step 1060). For example, if the computed average latencyexceeds some specified threshold level, the network would be overloadedor not available, but if the computed average latency is less than orequal to the specified threshold level, the network would be available.Note that the determination of “network performance” by the networkmonitor in step 980 in FIG. 9 relates to whether the network isoverloaded in step 1060 in FIG. 10, and may be determined using anysuitable heuristic or criteria.

Method 1000 in FIG. 10 may be performed at set time intervals so thenetwork characteristics are constantly updated regardless of when theyare used. Of course, in the alternative method 1000 could be performedon-demand when the network characteristics are needed. The benefit ofdoing method 1000 on-demand when the network characteristics are neededis the data will be as fresh as it can be. The downside of doing method900 on-demand when the network characteristics are needed is the delaythat will be introduced by the network monitor 142 determining thenetwork characteristics. Having the network monitor periodically gatherthe network characteristics means these characteristics are readilyavailable anytime the query optimizer needs them. The period of theinterval may be adjusted as needed to balance the performance of thesystem with concerns of the data being too stale.

The detailed description introduces a method and apparatus for a queryexecution monitor to monitor query execution on multiple networks in aparallel computer system. The query execution monitor determines whetherthere is a network failure and then uses the query optimizer to use adifferent network networks to complete the query. The query executionmonitor allows a database system to better utilize system resources of amultiple network parallel computer system.

One skilled in the art will appreciate that many variations are possiblewithin the scope of the claims. Thus, while the disclosure isparticularly shown and described above, it will be understood by thoseskilled in the art that these and other changes in form and details maybe made therein without departing from the spirit and scope of theclaims.

1) A computer apparatus comprising: a plurality of nodes each having amemory and at least one processor; a database residing in the memory; aplurality of networks connecting the plurality of nodes; a queryoptimizer and a query to the database residing in the memory; and aquery execution monitor residing in the memory and executed by the atleast one processor, wherein the query execution monitor detects anetwork failure during execution of the query and invokes the queryoptimizer to re-optimize the query to use a different network resourceto execute the query. 2) The computer apparatus of claim 1 wherein thequery execution monitor determines part of the query executed prior tothe network failure and then modifies the query to utilize data from thepart of the query that executed prior to the network failure. 3) Thecomputer apparatus of claim 1 further comprising a network file that isused by the query execution monitor and wherein the network filecontains network file information selected from the following: networkID, a timestamp, current utilization, future utilization, availability,latency and retransmits. 4) The computer apparatus of claim 3 furthercomprising a network monitor that stores information about the pluralityof networks in the network file. 5) The computer apparatus of claim 4wherein the query execution monitor determines the network failure basedon the information in the network file indicating a network resource isbelow a threshold. 6) The computer apparatus of claim 1 furthercomprising a service node connected to the plurality of nodes thatcontrols the plurality of nodes, and a network monitor that periodicallymonitors the plurality of networks to determine network loading. 7) Thecomputer apparatus of claim 1 wherein the query optimizer re-optimizesthe query for a potential failure and stores an alternate access plan tobe used when the query execution monitor detects the occurrence of thepotential failure. 8) A computer implemented method for optimizing aquery on a parallel computer system comprising the steps of: receiving aquery to a database; optimizing the query; initiating the queryexecution; monitoring the query execution; detecting a network failure;and in response to the detected network failure, optimizing tore-optimize the query to use a different network resource to execute thequery. 9) The computer implemented method of claim 8 further comprisingthe step of determining that part of the query executed prior to thenetwork failure and then modifying the query to utilize data from thepart of the query that executed prior to the network failure, where themodifying the query step is done prior to re-optimizing the query. 10)The computer implemented method of claim 8 further comprising the stepof creating a network file that is used contains network fileinformation selected from the following: network ID, a timestamp,current utilization, future utilization, availability, latency andretransmits. 11) The computer implemented method of claim 10 furthercomprising the step of determining the network failure based on theinformation in the network file indicating a network resource is below athreshold. 12) The computer implemented method of claim 8 wherein thestep of monitoring the query is done on a service node connected to aplurality of nodes of a massively parallel computer system with aplurality of network, and a network monitor in the service nodeperiodically monitors the plurality of networks to determine the networkfailure. 13) The computer implemented method of claim 8 wherein thequery optimizer re-optimizes the query for a potential failure andstores an alternate access plan to be used when the query executionmonitor detects the occurrence of the potential failure. 14) An articleof manufacture for executing on a parallel computer system with aplurality of compute nodes comprising: a query execution monitorperforming the steps of: receiving a query to a database; optimizing thequery; initiating the query execution; monitoring the query execution;detecting a network failure; in response to the detected networkfailure, re-optimizing the query to use a different network resource toexecute the query; and computer-readable medium in which computerinstructions are stored, which instructions, when read by a computer,cause the computer to perform the steps of the query execution monitor.15) The article of manufacture of claim 14 wherein the query executionmonitor further performs the steps of: determining that part of thequery executed prior to the network failure and then modifying the queryto utilize data from the part of the query that executed prior to thenetwork failure, where the modifying the query step is done prior tore-optimizing the query. 16) The computer apparatus of claim 14 furthercomprising the step of creating a network file that is used containsnetwork file information selected from the following: network ID, atimestamp, current utilization, future utilization, availability,latency and retransmits. 17) The computer apparatus of claim 16 furthercomprising the step of determining the network failure based on theinformation in the network file indicating a network resource is below athreshold 18) The article of manufacture of claim 14 wherein the step ofmonitoring the query is done on a service node connected to a pluralityof nodes of a massively parallel computer system with a plurality ofnetwork, and a network monitor in the service node periodically monitorsthe plurality of networks to determine the network failure. 19) Thearticle of manufacture of claim 14 wherein the query optimizerre-optimizes the query for a potential failure and stores an alternateaccess plan to be used when the query execution monitor detects theoccurrence of the potential failure.